The subject matter discussed in the background section should not be assumed to be prior art merely as a result of its mention in the background section. Similarly, a problem mentioned in the background section or associated with the subject matter of the background section should not be assumed to have been previously recognized in the prior art. The subject matter in the background section merely represents different approaches, which in and of themselves may also be inventions.
An on-demand system typically includes multiple nodes, such as application servers, that interact with a relational database management system. Each of the nodes may convey selected data updates from a relational database to multiple clients that subscribe to the on-demand system. Each node typically accesses the relational database management system to identify each of the data updates based on timestamps corresponding to the data updates. For example, after an application server conveys selected data updates from the relational database to subscribing clients beginning at 9:00 AM, the relational database management system receives data updates at 9:19 AM, and the application server checks for additional data updates at 9:30 AM by examining the timestamps of the data updates in a transaction table stored in the relational database. The application server skips the data updates with a timestamp from before 9:00 AM because the application server presumably processed these data updates already beginning at 9:00 AM, and only attempts to process the data updates with timestamps between 9:00 AM and 9:30 AM.
However, the relational database management system may receive data updates in bursts, such as 2 million data updates between 9:00 AM and 9:30 AM at 9:19 AM, and no data updates between 9:30 AM and 10:00 AM. Although the relational database management system may have the capacity to receive and process millions of data updates in a short period of time, an application server may not have the capacity to process millions of data updates before the application server is scheduled to process data updates again. Therefore, when the application server is scheduled to process data updates again at 10:00 AM, the application server may not have completed the processing of the 2 million data updates that the application server began processing at 9:30 AM. In this situation, the application server may malfunction, and even crash. The application server may terminate the 9:30 AM job before all of the 2 million data updates were processed, such that the application server does not process the unfinished data updates because these unfinished data updates have 9:19 AM timestamps and the 10:00 AM job only processes updates with timestamps after 9:30 AM, when all of the previous data updates were presumed to have already begun processing. Even though many data updates remain unprocessed, the application server may be idle because no data updates exist with a timestamp between 9:30 AM and 10:00 AM. Alternatively, the application server may begin reprocessing some of the data updates that the application server already processed beginning at 9:30 AM, which may not only waste resources, but also result in yet another job timeout before all of the data updates are processed. Further problems may exist when an application server is taken offline for scheduled maintenance or to repair a problem. When the application server is bought back online, the timestamp of the application server's most recent job may be so long ago relative to the recent data updates that the application server may experience many problems, including some of the problems described above, in an attempt to process all of the data updates that occurred during the application server's downtime.